1. Field of the Invention
The present invention relates in general to telecommunications systems and more particularly to a method and system for monitoring telecommunications traffic. The invention can be used to facilitate numerous enhanced telecommunications services. For purposes of illustration, however, the invention will be described principally in the context of facilitating account-balance based telecommunications services, such as prepaid calling. Further, the invention is useful both in landline and wireless communication networks.
2. Description of Related Art
For many years, the telecommunications industry has recognized the need to provide a mechanism for restricting or otherwise managing use of communication services based on a measure of subscriber account balance. In such systems, a subscriber (e.g., a corporation, an individual or another party) typically arranges with a service carrier to establish an account balance that typically represents a measure, such as time or dollar value, of telecommunications services that the subscriber is authorized to use. As the subscriber uses the services, the carrier may then continuously monitor and decrement the account balance. When the balance drops to a low threshold level, the carrier may notify the subscriber. And once the balance is exhausted, the carrier may refuse to provide additional services or may continue to provide service and then bill the subscriber for the excess use.
Traditionally, such xe2x80x9caccount balancexe2x80x9d services have taken the form of xe2x80x9cprepaidxe2x80x9d service, where a subscriber deposits a prepayment amount with a service provider, and the service provider allows the subscriber to use services only up to the amount prepaid. When the subscriber approaches the prepaid limit during a call, the service provider might then prompt the subscriber to recharge or refill the account, and the subscriber may add to the account balance by making an additional prepayment, as for instance with a credit card.
Offered for years in both landline and wireless systems, prepaid service has been viewed largely as a tool to attract xe2x80x9ccredit challengedxe2x80x9d consumers, that is, potential customers with poor credit histories or who otherwise lack adequate credit references. In addition, prepaid service appeals to consumers who do not want to be burdened with contracts and bills, who want to maintain fixed budgets, or who simply wish to remain anonymous. For example, travelers who
require temporary phone service can benefit from prepaid service in the form of a prepaid calling card or a rented wireless phone that has been activated with prepaid minutes. Similarly, a calling card or pre-activated wireless phone with initial prepaid minutes can be given, sold or rented through various channels, including supermarkets and convenience stores.
The concept of account balance services, however, encompasses more than just traditional prepaid communications. In general, an account balance service can involve establishing or applying any type of account balance that serves as an actual or suggested limit on use of communications services. The account balance could represent a time limit such as minutes of use, or a financial limit such as dollars of use, for example. Further, the account balance that defines the actual or suggested limit on use need not necessarily come from a prepayment by a subscriber or other party. Rather, the account balance could simply represent an assigned limit on use, which the subscriber may or may not be allowed to exceed.
For example, a corporation may arrange with a telecommunications carrier to provide wireless communication service for its employees and may set up an account balance for each employee defining a maximum time or cost of use by the employee per month. The carrier may then bill the corporation for the use per employee up to the preset limit and may bill the corporation or employee for any excess use. As another example, parents may subscribe to an account balance service for a child in order to limit the child""s use to a preset limit per month. At the end of each month, the carrier may then bill for the child""s actual use, up to the preset limit.
In order to provide account balance service, a telecommunications network should include some mechanism to track the start and stop of calls, to monitor and adjust a subscriber""s balance during a call, and to maintain control of the call in order to facilitate an appropriate response to a low or zero balance. Several methods currently exist to provide this functionality in today""s intelligent telecommunications networks.
A general example of an advanced intelligent network (xe2x80x9cAINxe2x80x9d) is depicted in FIG. 1 and is designated generally by reference numeral 10. In this figure, circuit-switched pathways (i.e., trunks) that carry voice and data are represented by solid lines, and signaling pathways and other logical connections are represented by dotted lines.
In exemplary network 10, a first station 12 is connected to the public switched telephone network (xe2x80x9cPSTNxe2x80x9d) 14 via a first service switching point (xe2x80x9cSSPxe2x80x9d) 16, and a second station 18 is connected to PSTN 14 via a second SSP 20. Stations 12 and 18 may be telephones, fax machines, modems, or other such devices. SSPs 16 and 20 are connected to each other and to a centralized service control point (xe2x80x9cSCPxe2x80x9d) 22 by a signaling network that includes a first and second signal transfer points (xe2x80x9cSTPxe2x80x9d) 24 and 26. This signaling network carries out-of-band signals that are used to control the switches and to set up and tear down the circuit between the calling party and called party. Currently, Signaling System 7 (xe2x80x9cSS7xe2x80x9d) is the most commonly used signaling system.
SCP 22 contains control information and call processing logic to assist SSPs 16 and 20 in handling calls. For this purpose, SSP 16 is programmed with logic that defines xe2x80x9ctrigger pointsxe2x80x9d at which SSP 16 should seek guidance from SCP 22. At these trigger points, SSP 16 sends a query message to SCP 22, and SCP 22 returns a response message to SSP 16. According to SS7,these query and response messages are known as Transaction Capabilities Application Part (xe2x80x9cTCAPxe2x80x9d) messages.
For example, SSP 16 may include a table that identifies a range of subscriber numbers associated with special services, and SSP 16 may be programmed with a trigger that causes SSP 16 to query SCP 22 in response to a call origination or termination attempt involving one of those numbers. At that trigger point, SSP 16 would send a TCAP query to SCP 22, providing various parameters such as the calling number and the called number. In turn, SCP 22 would execute service logic to determine what SSP 16 should do with the call, and SCP 22 would then send a TCAP response back to SSP 16. The TCAP response may instruct SSP 16 to route the call to a particular destination or may provide various other instructions or information.
Alternatively, SSP 16 may itself be programmed with logic that indicates how to handle special service calls, without requiring SSP 16 to xe2x80x9cdipxe2x80x9d into the logic of SCP 22. For instance, in response to a call origination or termination attempt involving a particular number, SSP 16 may execute its own logic to determine what to do with the call. Internal tables and service logic programmed into SSP 16 may then instruct the SSP to route the call via a particular trunk group to a remote destination in the network.
On call origination, once an SSP receives routing instructions from SCP 22 or otherwise determines where in the network to route a call, the SSP may seek to set up a call with a switch serving the terminating location, by engaging in an SS7 signaling session. According to SS7, call setup and tear down between switches is accomplished by a series of messages in the Integrated Services Digital Network User Part (xe2x80x9cISUPxe2x80x9d) layer. These messages include the initial address message (xe2x80x9cIAMxe2x80x9d), the address complete message (xe2x80x9cACMxe2x80x9d), the answer message (xe2x80x9cANMxe2x80x9d), the release message (xe2x80x9cRELxe2x80x9d) and the release complete message (xe2x80x9cRLCxe2x80x9d), among others. The ISUP protocol is defined by ITU-T recommendations Q.761 and Q.764, as well as Bellcore GR-317 CORE and GR-394 CORE, all of which are fully incorporated herein by reference.
To set up a call from station 12 to station 18, SSP 16 first sends an IAM message to SSP 20 via STPs 24 and 26. The IAM message indicates that the originating switch has seized an outgoing circuit, and provides address information (such as the dialed number) and other parameters related to routing and handling of the call. In response, SSP 20 sends an ACM message to SSP 16, to acknowledge that all address signals required for routing the call to the called party have been received and that the call can be connected to station 18. When station 18 goes off hook to answer the call, SSP 20 sends an ANM message back to SSP 16 to signal that station 18 has answered. In response, SSP 16 connects the call to SSP 20, thereby establishing an end-to-end communication path between station 12 and station 18.
To tear down a call between station 12 and station 18 (e.g., in response to an on-hook event at station 12, for instance), SSP 16 sends a REL message to SSP 20, indicating that the circuit identified in the message is being released for a specified reason and is ready to be put into an idle state upon receipt of a RLC message. SSP 20 then sends a RLC message to SSP 16, thereby putting the circuit into an idle condition.
In exemplary network 10, SCP 22 is for connected with a service management system (xe2x80x9cSMSxe2x80x9d) 28 that allows for the provision and modification of the information and service logic residing in the SCP. SMS typically includes a user interface, the service creation environment (xe2x80x9cSCExe2x80x9d) 30, which may be accessed by a computer terminal 32. In this way, a user at terminal 32 is able to access, create and modify the service logic and other information in SMS 28 and then download it to SCP 22.
In addition, SSP 16 is connected to a service node (xe2x80x9cSNxe2x80x9d) 34, which can provide voice and other interactions with users and can facilitate and perform various enhanced services for the switch. For this purpose, SN 34 may contain programmed service logic, which SN 34 may execute in response to messages received from SSP 16. In addition, SN 34 may contain an intelligent voice response unit (xe2x80x9cIVRUxe2x80x9d) or other hardware and software to facilitate interaction with users, such as playing announcements, collecting dual-tone-multi-frequency (xe2x80x9cDTMFxe2x80x9d) digits, and recognizing speech. As shown in FIG. 1, a service node such as SN 34 is typically connected to a switch. Consequently, the network may include many service nodes, each programmed to perform the same or similar services for its respective switch.
Finally, exemplary network 10 includes an intelligent peripheral (xe2x80x9cIPxe2x80x9d) 36, to which SSP 16 and SCP 22 are connected, possibly through one or more STPs. Like SN 34, IP 36 can connect to an AIN call and can be arranged to provide assorted services, including tone generation, voice recognition, playback, compression, call control, recording, and DTMT detection and collection. IP 36 may similarly include an IVRU to facilitate various interaction with users. IP 36 can be connected to one or more SSPs and is designed to be application-independent, supporting generic services for more than one application. Unlike SN 34, IP 36 does not have call control logic embedded and must be instructed to perform each operation under the control of SCP 22 using a TCP/IP communication path to SCP 22 and the Bellcore defined SR-3511 ISCP-IP Interface Specification. This standard is fully incorporated herein by reference.
The exemplary network illustrated in FIG. 1 can be implemented in both landline and wireless systems. In the landline environment, the network is referred to as an advanced intelligent network (xe2x80x9cAINxe2x80x9d). In the wireless environment, the network is referred to as a wireless intelligent network (xe2x80x9cWINxe2x80x9d). The principal difference is that, in a landline system, station 12 is directly connected to SSP 16, whereas, in a wireless system, station 12 is a mobile station (xe2x80x9cMSxe2x80x9d) that communicates via radio waves with a base station (xe2x80x9cBSxe2x80x9d) and in turn with SSP 16 (referred to as a mobile switching center (xe2x80x9cMSCxe2x80x9d)). In addition, other differences in operation exist between landline and wireless intelligent networks, due largely to differences in industry standards for the two environments. AIN standards are currently embodied in Bellcore""s AIN Release 0.1 and AIN Release 0.2, while WIN standards are currently embodied in Telecommunications Industry Association (xe2x80x9cTIAxe2x80x9d) interim standard IS-771 (which is based on other industry standards, including interim standard IS-41, now known as ANSI/TLA/EIA-41-D, for instance.) Each of these standards is fully incorporated herein by reference.
As indicated above, several systems exist for providing account balance functionality in an intelligent network. In one arrangement, when a switch receives an account balance call, the switch responsively routes the call through a specially programmed service node before routing the call to its destination. This arrangement thus inserts the service node in the voice path of the call, so that the service node is able to perform call timing, interject announcements, collect digits, and disconnect the call as necessary. FIG. 2 illustrates this xe2x80x9cdedicated service nodexe2x80x9d scenario by way of example.
As shown in FIG. 2, SSP 16 is connected to SN 34 by a pair of voice trunks 38 and 40. When SSP 16 receives dialed digits from station 12, SSP 16 determines that the call is an account balance call, by consulting an internal translation table or by querying SCP 22. In response, rather than setting up a call directly with SSP 20, SSP 16 routes the call over voice trunk 38 to SN 34, together with address information including the calling number and dialed number. Upon receipt of the call, service node 26 communicates with a customer information system (not shown) or other database to determine the caller""s account balance. If the account balance is a minimum necessary to support a call from station 12 to station 16, then SN 34 routes the call via trunk 40 to SSP 16 with instructions for SSP 16 to route the call to its destination. In turn, SSP 16 sets up and connects the call from to SSP 20 and ultimately to station 18.
With this arrangement, a xe2x80x9chairpinxe2x80x9d or physical trunk path is established from station 12, through SSP 16, through SN 34, back to SSP 16, through PSTN 14 and SSP 20, and finally to station 18. This trunk path is depicted by the bold line 42 in FIG. 2. Because SN 34 sits in this trunk path, SN 34 can readily monitor the start and stop of the call, interject announcements, and take the call back (e.g., cut off the call) if desired. Thus, for instance, if the caller""s account balance drops to a low threshold level during the call, SN 34 may break into the call and play a low-balance announcement along trunk 40 to station 12. SN 34 may then allow the caller to recharge the account balance, by making a credit card payment through DTMF tones for instance, and SN 34 may forward the renewed balance information to the account balance database and allow the call to continue.
Further, if the caller""s account balance reaches zero, the programmed service logic in SN 34 may dictate that the call should be disconnected. In that case, SN 34 may play an announcement or tone indicating a zero balance and may then release the connection with station 18 along voice trunk 38, thereby disconnecting the call. If desired, service node 26 may then remain connected to station 12 until the caller hangs up, to allow the caller to recharge the account.
The dedicated service node arrangement shown in FIG. 2 is presently the most common mechanism for prepaid calling services. The arrangement requires very little if any special intelligence to be programmed into the switches or SCP. However, the arrangement suffers from at least two significant limitations. First and foremost, the arrangement monopolizes two voice trunks between SSP 16 and SN 34, solely to keep SN 34 within the voice path. Voice trunks serving SSP 16 are an expensive and limited resource. Therefore, this method is not desirable. Second, because a service node such as SN 34 is typically connected to a particular switching point such as SSP 16, a carrier may have to program the same functionality into many service nodes throughout its network in order to offer prepaid functionality to users throughout the network. Unfortunately, however, implementing or updating this duplicate functionality is both time consuming and expensive.
In another arrangement, the responsibility for managing and tracking account balance calls is migrated in part to SCP 22, by placing the SCP in a so-called ISUP xe2x80x9clooparoundxe2x80x9d signaling path with SSP 16. In this method, SSP 16 is programmed with logic authorizing SSP 16 to route calls to SCP 22 as though SCP 22 were a switch (while, in fact, the SCP is usually incapable of actually receiving calls). Rather than seeking to route such calls along a normal trunk connecting SSP 16 and SCP 22, however, SSP 16 is programmed to route such calls along a special xe2x80x9clooparound trunkxe2x80x9d (the xe2x80x9coutbound looparound trunkxe2x80x9d) at SSP 16 which has been tied together with another trunk (the xe2x80x9cinbound looparound trunkxe2x80x9d) at SSP 16. Thus, when SSP 16 receives a prepaid call to or from station 12, SSP 16 seeks to set up the call to SCP 22 along the outbound looparound trunk by sending an initial IAM message to SCP 22. In response, SCP 22 surreptitiously returns an IAM message to SSP 16 purporting to set up the same call along the inbound looparound trunk. Upon completion of call setup, the net result is that SSP 16 ends up routing the call to itself, from the outbound looparound trunk to the inbound looparound trunk, and then to a destination, while leaving a signaling path for the call through SCP 22. Consequently, because SCP 22 sits in the signaling path of the call, it can time the call, track the subscriber""s account balance, and release the call when the balance is depleted.
FIG. 3 illustrates this looparound arrangement in greater detail. Referring to FIG. 3, SSP 16 is coupled to a plurality of trunks for establishing circuit switched communications with other locations in network 10. A pair of these trunks 44, 46 are tied together at SSP 16 for establishing looparound with respect to SCP 22. Although FIG. 3 shows only one pair of such looparound trunks, SSP 16 would include a number of looparound pairs sufficient to serve an expected number of prepaid customers.
To facilitate looparound, SCP 22 is modified to include ISUP messaging capability, including the ability to receive and parse ISUP messages (such as IAM messages) and to create and send ISUP messages. In addition, SCP 22 is coupled by a SR-3511 signaling path to an IVRU 52, which may be part of a service node or intelligent peripheral platform, and IVRU 52 is coupled by a voice trunk to PSTN 14.
When SSP 16 receives a prepaid call request from station 12, SSP 16 consults its internal translation table and service logic, which dictates that the account balance call should be routed via outbound looparound trunk 44 to SCP 22. SSP 16 then seeks to set up the call by sending a first IAM message (IAM1) to SCP 22 requesting a call connection via outbound looparound trunk 44. Upon receipt of IAM1, SCP 16 does not immediately respond with an ACM message. Instead, SCP 22 directs SSP 16 to connect the call to IVRU 52 so that IVRU 52 can announce the subscriber""s balance. To do so, SCP 22 queries IVRU 52 to identify an available trunk at the IVRU, and SCP 22 then sends a second IAM message (IAM2) to SSP 16, instructing SSP 16 to receive a call on inbound looparound trunk 46 and to route it to IVRU 52 via trunk 48. SSP 16 then responds to IAM2 by sending an ACM message (ACM2) to SCP 16, and SCP 22 then responds to IAM1 by sending an ACM message (ACM1) to SSP 16.
Next, SSP 16 sets up and connects the call to IVRU 52 via trunk 48 and PSTN 14. In turn, IVRU 52 sends an ANM message (ANMA) back to SSP 16, SSP 16 forwards ANMA via to SCP 22, and SCP 22 forwards ANMA to SSP 16. The result of this signaling is to establish a looparound circuit 54 as shown in FIG. 3, with an ISUP signaling path extending through SCP 22 and the associated voice path coupling trunks 44, 46 at SSP 16, thereby connecting station 12 with IVRU 52. With this connection established, IVRU 52 plays an announcement to the subscriber, indicating the available account balance. IVRU 52 then releases the call leg of trunk 48, by sending a REL message (RELA ) to SSP 16. In response, SSP 16 forwards the RELA back to SCP 22 which responds to SSP 16 with a RLC message. SCP 22 does not release back to SSP 16 however, but then sends a third IAM message (IAM3) to SSP 16 to interconnect trunks 46 and 50 and set up a call with the final destination switch, SSP 20. Thus, SCP 22 sends the third IAM message to remote SSP 20 requesting connection over trunk 50, and SSP 20 sends an ACM message (ACM3) back to SSP 16 which is forwarded by SSP 16 to SCP 22.
When station 18 answers, SSP 20 sends an ANM message (ANMB) to SSP 16, and SSP 16 forwards ANMB to SCP 22 thereby closing the signaling and voice paths between stations 12 and 18. Finally, when the call terminates (from station 12), a REL message (RELB) will pass from SSP 16 to SCP 22. SCP 22 will then send a RLC message back to SSP 16 and a REL to SSP 20 which will pass a RLC message back to SCP 22 terminating both legs of the looparound trunk 46.
With this arrangement, the signaling path remains through SCP 22 throughout the duration of the call, while the actual call path is defined by looparound circuit 54. Because SCP 22 sees the ISUP messages concerning the status of the call (e.g., ANM and REL messages), SCP 22 can keep track of the start and stop of the call, recording these events in a call context (i.e., call status) register. Consequently, SCP 22 can time the call and accordingly decrement the subscriber""s account balance. Further, SCP 22 can monitor the subscriber""s balance as the call proceeds and can readily disconnect the call in response to a depleted balance by sending a REL message to SSP 16.
Although this SCP-looparound arrangement facilitates prepaid functionality, it suffers from a significant limitation: namely, it restricts prepaid customers to a predefined set of calling numbers that are associated with prepaid service. This predefined set of numbers has to be programmed into the switch so that the switch can appropriately recognize prepaid calls and then route such calls via the looparound trunk.
Restricting subscribers to a predetermined set of numbers for prepaid service is problematic from several perspectives. First, it forces the service provider to dedicate a set of numbers to prepaid service and to program every switch in the network with the set of numbers. This therefore assumes that the service provider can determine accurately how many numbers to dedicate for such service at the start, and the service provider risks reserving too many or too few numbers for this purpose. Further, limiting subscribers to a dedicated set of numbers could present difficulty in terms of attracting new customers, since this restriction may force new customers to change their phone numbers (to a xe2x80x9cprepaid phone numberxe2x80x9d) in order to acquire the service. For customers with personalized or xe2x80x9cvanityxe2x80x9d numbers, this is particularly troubling.
Still another arrangement for providing account balance service has been recently proposed within the international standards committee that is responsible for wireless communications standards, TIA Standard Committee TR-45. In particular, in an effort to facilitate seamless roaming among competitive WIN networks, the TIA has published a draft recommendation for xe2x80x9cprepaid-chargingxe2x80x9d enhancements to IS-771, which is set forth in xe2x80x9cUWC Pre-Paid Charging Stage 2xe2x80x9d (xe2x80x9cPPC-2xe2x80x9d), TR45.2.2.4 (January 19, 1999). According to PPC-2, prepaid service can be facilitated by implementing a variety of new WIN triggers and operations in network entities. Chief among these new triggers and operations are the following:
Initial_Origination and Initial_Termination triggers, which the MSC can use to invoke prepaid service logic for calls originated from or terminated to a prepaid subscriber.
Calling_Routing Address_Available and Called_Routing_Address_Available triggers, which the MSC can use to convey routing address and call type information for prepaid calls to service logic.
O_Answer, T_Answer, O_Suspend, O_Disconnect and T_Disconnect triggers, which the MSC can use to notify service logic of a call answer or disconnect for calls originating from or terminating to a prepaid subscriber.
(See PPC-2, at pages 1-4.) As proposed, these triggers would be programmed into each MSC in a WIN-compliant network and would enable the MSC to interact with a WIN SCP and an IP, so as to facilitate prepaid functionality.
Referring again to the exemplary network shown in FIG. 1, the proposed PPC-2 standard would operate as follows, where the prepaid subscriber originates a call from station 12 (which may be mobile station MS 12) by sending dialed digits to SSP 16 (which may be mobile switching center MSC 16). (See Section 8.X.2 of PPC-2). Upon receipt of the dialed digits, MSC 16 sends an IS-771 origination request message (ORREQ) to SCP 22, providing parameters such as the mobile station ID and the dialed digits. In response, SCP 22 determines that intelligent peripheral IP 36 needs to play an announcement of the subscriber""s available balance. Therefore, SCP 22 sends an IS-771 seize resource message (SEIZRES) to IP 36, requesting a routing number for routing a call from MSC 16 to IP 36. IP 36 responds by allocating a temporary location directory number (xe2x80x9cTLDNxe2x80x9d) to a port at IP 36 and returning the TLDN as a parameter in a response message to SCP 22. SCP 22 then sends an IS-771 connect-to-resource message (CONNRES) to MSC 16, instructing SSP 16 to set up a call to the allocated TLDN at the IP, and MSC 16 sets up the call.
Once the call is set up between MSC 16 and IP 36, IP 36 asks SCP 22 for instructions, and SCP 22 instructs IP 36 to play a balance-announcement. IP 36 then plays the balance-announcement to the user at MS 12 and tells SCP 22 it has done so. In turn, SCP 22 sends a closing message (anlyzd) to MSC 16, and MSC 16 disconnects the call from IP 36.
According to the recommendation, MSC 16 next sets up a call to the number dialed by the originating subscriber and, when the called party answers, MSC 16 detects the O_Answer trigger and responsively sends an O_ANSWER message to SCP 22. Upon receipt of the O_ANSWER message, SCP 22 begins decrementing the subscriber""s account balance. In turn, when MS 12 ends the call, MSC 16 detects the O_Disconnect trigger and responsively sends an O_DISCONNECT message to SCP 22. Upon receipt of the O_DISCONNECT message, SCP 22 stops decrementing the subscriber""s account balance.
The method proposed by PPC-2 would appear to readily facilitate prepaid functionality in wireless communications. However, the proposed method suffers from a very significant limitation: to ensure seamless operation, the method would require all of the switches in the WIN-compliant network to be programmed with the new PPC-2 capability set, including the new triggers and operations listed above. Unfortunately, upgrading all of the existing MSCs in a WIN network to become compliant with PPC-2 would be very expensive and time consuming. In fact, it is anticipated that the industry will not be ready to begin widely implementing PPC-2 for at least several years. Furthermore, as is conventional in industry standards, the PPC-2 recommendation defines new functions but leaves specific implementation decisions to the industry. Therefore, actual implementation of the proposed standard will be subject to interpretation by competing manufacturers and carriers, which could result in interoperability problems.
In view of the deficiencies in the art, there remains a need for an improved system for providing account balance service.
The present invention provides a method and system for monitoring telecommunications traffic. As indicated above, the invention may be usefully employed to offer a variety of special services. One of these services is account balance calling, and the invention will be described mainly in that context.
Generally speaking, an exemplary embodiment of the invention operates as follows. When a switch (such as an MSC) receives an originating or terminating call request for a subscriber (e.g., a particular station or customer) signed up for a special service such as account balance calling, the switch sends a request message to a service controller such as an SCP. The switch may do so in response to an all-digits trigger, for instance. When the SCP receives the request message, it consults a service profile table and determines that the call is a predefined type of call, namely a call to be treated according to the special service. Therefore, the SCP sends a response message to the switch with a service-code indicative of the special service, together with a destination address to which the call should be routed. For instance, if the service code for account balance calling is *65 and the destination address is 988-765-4433, the SCP might send as the destination address *65-988-765-4433. The destination address may be the network address of a designated network element, such as an IP (or the SCP itself) for instance.
In response to the service code, the switch determines by reference to a conventional translation table for instance, that the call should be routed via an outbound looparound trunk to the destination IP address specified by the SCP. Therefore, the switch sends an IAM message to set up the call with the IP on that trunk. When the IP receives the iAM message, it may consult the SCP to receive instructions for proceeding and, in the case of an account balance call, to learn the available account balance. The IP then sends its own IAM message back to the switch, to complete a looparound circuit at the switch and to cause the switch to route the call to particular destination. The particular destination may, for instance, be the IP itself. In that case, for an account balance call for instance, the IP might play an announcement to the subscriber indicating the available balance, and the IP could then release the last call leg and send an IAM message to the switch directing the switch to route the call to the called party.
As the call begins and ends, the IP will be privy to the ISUP setup and teardown messages for the call. When the IP sees these messages, it may advise the SCP, and the SCP may take any appropriate action. For an account balance call, for instance, the SCP may time the call based on these messages and decrement the account balance accordingly. Further, the SCP may interact with an external call calculation engine, which may maintain or have access to account balance information. When the balance becomes too low, the SCP may then instruct the IP to take the call back, such as by sending a REL message to the switch, and to play an announcement or collect digits or additional prepayment.
The present invention enables a telecommunications carrier to provide special services that require special routing (such as via a looparound trunk) broadly to any telephone number, without the need for subscribers to dial feature codes to trigger the service, and without the need to program switches with extensive new functionality and message sets. By having the SCP identify the call as a predefined type of call and then provide the switch with a service code for that type of call, the switch can be made to route the call via a looparound trunk, regardless of the subscriber""s number. Thus, with the present invention, a telecommunications carrier, agent or subscriber can readily apply account balance service to a subscriber account by simply setting up an account balance and updating the service profile for the account.
Accordingly, the present invention lends itself to new and improved provisioning methods and service offerings. For instance, it may be possible to open up a service profile database (e.g., through an SMS) to modifications by subscribers, customer service agents, retail sales agents or the like. A web-based interface over the Internet or other network, for example, may allow a subscriber to add or modify a special service for his or her account. For example, through a web-based interface, a subscriber may be allowed to call up his or her service profile (e.g., for a landline station and/or mobile station) and add account balance service by making a prepayment or by otherwise specifying an actual or suggested limit on use. As another example, a retail outlet selling or renting mobile stations may readily call up the service profiles for the mobile stations and set up account balance service for the stations, with prepayment by the customer. Other examples exist as well.
These as well as other advantages of the present invention will become apparent to those of ordinary skill in the art by reading the following detailed description, with appropriate reference to the accompanying drawings.